home *** CD-ROM | disk | FTP | other *** search
Text File | 1988-12-01 | 63.5 KB | 1,741 lines |
-
-
- INDRA
- Working
- Paper
-
-
-
- INDRA Note 1025
- IEN 169
- 23rd January 1981
-
-
-
-
-
-
-
-
-
-
- A Simple NIFTP-Based Mail System
-
-
-
- C. J. Bennett
-
-
-
-
-
- ABSTRACT: This INDRA Note proposes a draft mail
- protocol for use in a wide variety of network
- situations. This protocol draws heavily on existing
- facilities and could be brought up very quickly - in
- months rather than years. It could thus be used as
- an interim solution until international standards
- emerge. An experiment in the ARPA Catenet is
- proposed, and the use of the system in the UK is
- discussed.
-
-
-
-
-
- Department of Computer Science
- University College London
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 1. Introduction
-
- One of the major uses of computer networks is for electronic
- mail services. Now that networking technology is proliferating
- rapidly, it is highly desirable that such services should be
- made available with the new networks. However, despite the
- recent adoption of Teletex proposals by CCITT, it may be some
- time before one can expect international standards to be
- finalised and widely available. Hence there is a strong need
- for a simple interim scheme, which could cover the basic needs
- for mail transfer across multiple networks and through
- intermediate mail relays in a flexible fashion. We at UCL are
- particularly concerned with this, as we see the need for a
- scheme which will operate both with the facilities available
- in the United States, and those rapidly becoming available in
- Britain and Europe.
-
- This note contains a proposal for such an interim protocol,
- discusses the requirements on mail relays, and also the
- requirements for experimental systems based on it, both in the
- US and the UK. Partly because the proposed system uses ARPA
- facilities, the document has a certain bias towards
- familiarity with ARPA systems and terminology. In particular,
- the note assumes familiarity with RFC733 mail formats
- [Crocker77], the ARPA standard. However, it is believed that
- the system will also be useful in other environments,
- particularly the X25 and Network Independent Transport Service
- [SG3/80] environments which will be available shortly in the
- UK. ARPA-oriented readers should note that familiarity is
- assumed with the NIFTP [HLPG81], the interim UK file transfer
- standard.
-
- Comments are solicited and welcomed.
-
-
- 2. Requirements
-
- The basic requirements for an immediate mail service are as
- follows:
-
- (1) Maximum use must be made of existing standards. No
- radical new mail formats, transfer protocols, etc may
- be imposed. Using these facilities it should be
- possible to bring up an initial service within months
- rather than years.
-
- (2) The service should be economic. In particular, only
- one copy of a message should be transmitted to each
- destination mail server.
-
-
-
-
- Bennett [Page 1]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- (3) The service should be independent of particular
- networks.
-
- (4) Address information must be transmitted in a way which
- is usable by mail relays.
-
- (5) Total global knowledge of mail server addresses should
- not be necessary.
-
- (6) The service should be as flexible as possible. Where
- possible it should be easy to extend it to meet new
- needs as they emerge.
-
- The last requirement is perhaps the least important. It
- implies that the service will be around for sufficiently long
- that experimental technical advances in message processing can
- be usefully incorporated. For instance, the minimum
- requirement is that text messages must be transferable.
- Requirement (vi) suggests that it should be possible to extend
- the service simply to transfer mixed-media messages. When
- assessing whether a given proposal meets this criterion, the
- multi-media case will be used as a test.
-
- No existing system in wide use meets all these constraints.
- Hence it is necessary to combine elements with the right
- properties from a number of sources not all of which are
- currently used for mail.
-
- It should be noted that the service defined here is not
- intended to be perfect. In particular, it does not of itself
- guarantee bidirectionality, endpoint reliability, or use of
- address lists. These will normally be available for direct
- endpoint transfer, and any problems are most likely to arise
- if intermediate relays are used. It is possible to support all
- these things using it, and of course they are encouraged.
- However, I feel that a service adequate for ordinary use can
- be achieved without defining a great deal of complicated
- additional mechanism to guarantee these properties. Finally,
- the problem of conversion between mail formats is not
- discussed at all.
-
-
- 3. Basic Elements
-
- 3.1 Mail Format
-
-
-
-
-
- Bennett [Page 2]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- The mail format defines the standards for the appearance of
- a message; it covers such things as the definition of header
- fields to allow messages to be processed by a standard
- program.
-
- The mail format most readily available is the ARPANET mail
- standard commonly known as RFC733, defined in [Crocker77],
- which is compatible with all except the last of the objectives
- listed above. RFC733 has been widely and successfully used for
- many years. In practice only a subset of the standard is
- actually used - in particular, the standard allows extended
- addressing by specifying destination networks, but no
- implementation supports this. It is proposed that the common
- subset of this standard be used. The only change suggested is
- that the text code should be IA5 rather than the Telnet
- version of ASCII, as IA5 is an international standard. In
- practice, the two codes are virtually identical. An example
- of an RFC733 message, and a summary of the RFC733 syntax, is
- given in Appendix I.
-
- This standard is completely text-oriented, for both message
- header (control) and message text (data) information. This
- makes it readily compatible with most of the text-processing
- software generally available on most interactive systems, such
- as text editors, pro forma preparation etc.
-
- Other formats may be agreed to in the near future. These may
- extended facilities, such as facsimile or multi-media mail.
- These can be accommodated provided any mail servers needing to
- process the mail body understand the format in use. Hence it
- may be necessary to provide a means for labelling the format
- in use. Such a label is not defined at this time.
-
-
- 3.2 Mail Addresses
-
- In any mail system it is essential to provide addresses for
- the mail recipient, and usually for the mail sender as well.
- While mail will frequently be transferred directly between the
- sender and the recipient, there will be occasions when it will
- be routed, and possibly temporarily stored, through an
- intermediate mail relay.
-
-
-
-
-
-
-
-
- Bennett [Page 3]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- Mail addresses are constrained to be compatible with the
- RFC733 format as generally used, viz. <username>@<hostname>.
- The <hostname> field defines the host used for an initial mail
- transfer, and in standard RFC733 usage, no further structuring
- is defined or required. If this name is understood by all
- message relays along a route, then no further structuring is
- ever required. If further structuring is required, it should
- be through the use of element separators in the <username>.
- The addressing structures encountered when mail relays must be
- used are discussed further in section 5.1.
-
-
- 3.3 Mail Transfer
-
- In addition to the appearance of the messages and the
- identity of the parties, it is necessary to define a protocol
- for transferring mail between the two. At first sight, it
- would seem natural to take over ARPA-developed procedures here
- too, so that one could use a complete, preexisting mail
- package. Despite the great success which have attended these
- procedures, and their undoubted appropriateness for the
- environment for which they were designed, they do not fulfil
- the needs of the wider message community, for reasons which
- are discussed below.
-
- The standard ARPANET Mail Transfer procedure [Postel76]
- fulfils only the first of the requirements listed in the
- introduction, and is therefore not acceptable. In particular,
- it has the following failings:
-
- (1) It is uneconomic in that it transmits one copy per
- destination user.
-
- (2) It is specific to the ARPANET.
-
- (3) It transfers address information in a way which is
- only usable for direct source/destination transfer.
-
- (4) It requires all hosts to be aware of all host names,
- and hence requires a globally understood global
- address space.
-
- (5) It can only ever handle text data. If binary data in a
- mixed-media message were encoded as text symbols and a
- code conversion was required between NVT-ASCII and a
- local text encoding, that data would be corrupted.
-
-
-
-
- Bennett [Page 4]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- A recent ARPA proposal [Sluizer80] for a new Mail Transfer
- Protocol (MTP) remedies in whole or in part some of these
- deficiencies. In particular, it provides facilities for
- economic uses of resources, and transfers addressing
- information in a way compatible with objectives (iv) and (v).
- However the MTP as it is currently proposed has some problems
- of its own:
-
- (1) The MTP allows a single copy of a message to be sent
- to multiple recipients, and is thus potentially more
- economic than the standard ARPA protocol. However,
- this is only an option which need not be implemented.
- Moreover, the mail sender can only specify one path
- for a given message to pass through intermediate
- relays. Thus MTP does not allow a single copy to be
- sent to a relay which could then decide to create
- multiple copies for different destinations at the
- point of a path division.
-
- (2) In MTP, address lists may be transferred either before
- or after the message body. With the 'recipients first'
- option, it is only possible to check the current
- validity of the addresses - for the actual message
- transfer, only total success and total failure can be
- indicated. If a given recipient became inaccessible
- for some reason between the two stages, the entire
- transfer would fail.
-
- (3) The MTP is defined to operate in an environment
- similar to that of the ARPA Catenet. In particular, it
- relies heavily on the use of Telnet command
- procedures, which are both little known and little
- used outside the ARPA community - especially within
- Europe. It does not define the mechanisms by which it
- will operate across more than one network (just as
- Telnet does not), or where Telnet procedures are not
- appropriate. To this extent, it is not network-
- independent.
-
- (4) The MTP provides no restart procedures to recover from
- errors signalled by either the host or the
- transmission medium. It is therefore only as reliable
- as the weakest underlying network. For example, an
- X25-based version could not recover from Resets.
-
-
-
-
-
-
- Bennett [Page 5]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- (5) It can only ever handle text data. If binary data in a
- mixed-media message were encoded as text symbols and a
- code conversion was required between NVT-ASCII and a
- local text encoding, that data would be corrupted.
-
-
- Accordingly, it is felt here that mail transfer outside the
- ARPA environment should use an alternative base. It is
- proposed here that mail transfer be achieved using defined
- conventions with the Network Independent File Transfer
- Protocol (NIFTP - [HLPG81]). This FTP is, as the name implies,
- network independent, has been implemented on a number of
- different existing networks, including the ARPANET and ARPA
- Catenet, and has been successfully used for direct file
- transfers across several intermediate networks. The revised
- version will be adopted as an interim standard in Britain and
- has evoked wide interest in Europe. There are numerous
- implementations of the existing version, and it is expected
- that the revised version will be implemented fairly rapidly
- after the new specification is released, which should be
- within the next two months. It thus meets the criteria of
- availability, standardisation and network independence. It
- remains to define a transfer procedure which meets the other
- criteria.
-
-
- 4. Point to Point Mail Transfer
-
- Using RFC733 mail formats and RFC733-compatible addressing,
- it is necessary to define the procedure used to transfer mail
- from a mail donor to a mail server with the NIFTP. This
- section defines that procedure.
-
-
- 4.1 Mail Structure
-
- 4.1.1 Proposal
-
- A letter shall be transferred as a single file from the mail
- donor to the mail server. The file name used shall be
- provided by the mail server. The structure of the file is as
- follows:
-
- <address list><one or more blank lines><mail text>
-
- The <address list> is a list of full, explicit RFC733
-
-
-
-
- Bennett [Page 6]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- addresses to whom the mail shall be distributed by the mail
- server.
-
- The <mail text> shall conform with RFC733 formats.
-
-
- 4.1.2 Discussion
-
- 4.1.2.1 Address Lists
-
- This structure is designed to fulfil the requirement that
- the service be economic. The passing of the <address list>
- minimises the number of copies of the message which must be
- made by the donor, but allows decisions to create additional
- copies to be made simply by intermediate relays.
-
- The <address list> must contain explicit addresses as the
- mail server is not necessarily able to access address lists,
- and in any case requires additional mechanism to do so. The
- addresses should be full (i.e. contain an explicit <hostname>
- component) as the server may be a relay using address mapping
- mechanisms (see below).
-
-
- 4.1.2.2 Possible Extensions
-
- There are two simple extensions which may be desirable:
-
- (1) To distinguish between message formats. This requires
- simply the addition of an extra field in the mail
- file, and the definition of text encodings. Such a
- field should be inserted between the <address list>
- and the <message text>. The use of other formats will
- particularly affect the design of mail relays.
-
- (2) Mailbagging. The file may contain several messages
- separated by defined message delimiters. (A simple
- one, which is widely used in message files on UNIX
- systems in the ARPANET, is ^A^A<cr>. Another
- alternative, preferred here, is to insert a
- delimitered character count, encoded in IA5, as in
- TENEX.) Mailbagging also has other implications. For
- instance, if the mail donor wishes to initiate a
- mailbagged transfer and it knows the name of an
- existing mailbag at the server from a previous
- transfer, it may append the file to the existing
-
-
-
-
- Bennett [Page 7]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- mailbag. The advantages of a mailbagging system are
- for further study.
-
-
-
- 4.1.2.3 Alternative Structures
-
- Two alternative structures were considered, both involving
- the explicit separation of the address list from the mail
- text.
-
- The first was to require the donor to specify the file name,
- which would be the address list. This has a number of
- disadvantages:
-
- (1) The NIFTP allows a maximum string length of 255
- characters for string-valued attributes. This would
- allow at most about 12-20 addresses.
-
- (2) It would be difficult to trace the progress of a
- message through a series of relays. With an explicit
- and known filename, it would be possible to initiate
- manual or automatic tracing procedures.
-
- (3) It is unlikely that most mail servers or relays would
- be able to use such a filename directly. The internal
- filename would be created using local mappings. The
- potential costs of these mappings could be very high.
-
-
- The second alternative considered was to transfer the
- address list and mail text as two separate files. This also
- has disadvantages:
-
- (1) The two files must be linked, e.g. by requiring that
- an Action Message be passed on STOP or STOPACK
- containing the filename to be used for the text
- portion of the transfer.
-
- (2) An additional level of error handling procedure must
- be defined, to cover cases such as the loss of a
- portion of the message text, or the arrival of two
- address lists with no intermediate message text.
-
-
-
-
-
-
-
- Bennett [Page 8]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- These problems are avoided by the mechanism proposed. By
- sending the address list and the body as a single file,
- address lists of arbitrary length can be sent; their link to
- the text is assured; maximum use can be made of the NIFTP
- reliability mechanisms; and the donor can be assured that the
- mail has at least reached the server host.
-
- The new MTP proposal from the ARPA community has a fairly
- similar proposal, but allows as an additional option the
- possibility of transmitting the text before the addressing
- data, arguing that in some cases this is more efficient for
- the destination host. Although it is conceivable that this may
- be true for MTP given the details of the MTP mechanisms, I
- think it is most unlikely that any advantage would be gained
- in the current context; moreover, in order to achieve it
- additional mechanism is required to specify which option is
- being used. Hence it has not been proposed.
-
-
- 4.2 Mail Server Identification
-
- 4.2.1 Proposal
-
- The mail server will be identified by its transport service
- subaddress. This subaddress will be network-specific and
- possibly host-specific; for instance, on the ARPANET it will
- be an NCP server socket, on the ARPA Catenet a TCP port, on
- public data networks an X25 or Transport Service subaddress as
- appropriate.
-
- If the mail donor and server are not on the same transport
- service, it is the responsibility of the intermediate virtual
- call gateways to perform any address transformations required,
- e.g. mapping the NCP mail socket to the TCP mail port.
-
-
- 4.2.2 Discussion
-
- This proposal is in line with the recommendation in the
- NIFTP specification for distinguishing different services
- utilising NIFTP. An alternative, which is not favoured here,
- is to reserve a value for the Username attribute, such as
- MAIL.
-
-
-
-
-
-
-
- Bennett [Page 9]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- 4.3 Mail Server Communication
-
- 4.3.1 Proposal
-
- Synchronisation shall be achieved via the establishment of
- an virtual connection between the mail donor and the mail
- server. This connection may be used for one or more mail
- transfers. The connection may have one or more segments, where
- each segment may use a different transport protocol.
-
-
- 4.3.2 Discussion
-
- This is normal NIFTP usage, and is essentially a restatement
- of the network-independence criterion.
-
- Normally, the donor and server will use the same transport
- protocol, and no additional procedures need be used.
- Exceptionally, the mail donor and server may not be on the
- same transport service. In this case direct NIFTP file
- transfer is still possible, but an additional degree of
- support is needed, through the provision of one or more
- virtual call gateways. At the least, the following services
- are necessary:
-
- (1) One-to-one connection mapping.
-
- (2) Addressing procedures. This could be any acceptable
- procedure, e.g. source routing, creation of a
- hierarchical address space, or mapping of transport
- service subaddress to destination host.
-
- (3) Call request facility. This carries all the addressing
- information necessary for establishing an end-to-end
- path.
-
- (4) Call accept facility. This is necessary to confirm
- that an end-to-end path has been established.
-
- (5) Data transfer. This should commence only after a call
- accept has been received.
-
- (6) Push preservation. Data should be forwarded if any
- push indication (e.g. TCP EOL, X25 No More Data) is
- received. The gateway may decide to forward data in
- other circumstances.
-
-
-
-
- Bennett [Page 10]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- (7) Closure propagation. If a connection closure is
- received from one side, it shall be mapped into the
- appropriate closure procedure on the other.
-
- (8) Reset propagation. If any network in the path is
- capable of generating resets, these must be forwarded
- in some fashion by the gateway. For instance, an X25
- RESET may be mapped into TCP URGENT. If resets cannot
- be generated this may be ignored by the gateway.
-
- It should be noted that the address transformations mentioned
- above need not be visible to the mail donor and server, and do
- not in any circumstances require address processing of the
- mail text at the virtual call gateway. For bidirectionality,
- however, it is necessary that the donor and server can
- recognise their respective hostnames as embedded in the mail
- file.
-
-
- 4.4 Mail Transfer
-
- 4.4.1 Proposal
-
- The transfer may be initiated by either the mail donor or
- the mail server.
-
- The file will be transferred by the NIFTP using IA5 text
- codes. If the file only contains a text message, then the Data
- Type attribute will indicate text only.
-
- If the transfer is initiated by the mail donor, then the
- Mode of Access used will be 'Replace or Make' and the Filename
- attribute on the SFT will indicate 'no value available'; the
- server should supply a value on the RPOS for reporting
- purposes.
-
- If the transfer is initiated by the mail server, then the
- Mode of Access used will be 'Read Only'. The donor will
- nevertheless often wish to delete the file after it has been
- successfully transferred. The Filename attribute on the SFT
- will supply a value.
-
- No other constraints are imposed on the use of NIFTP
- attributes.
-
-
-
-
-
-
- Bennett [Page 11]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- 4.4.2 Discussion
-
- This section defines the actual mail transfer procedure, and
- places minimal restrictions on NIFTP use.
-
- Alternative structures lead to greater restrictions or
- special interpretation of NIFTP attributes, or both.
-
- If a message format other than RFC733 is used, then mixed-
- media transfers may be possible. The NIFTP procedure would
- then have to be modified. If the file contains a mixed-media
- message, then the Data Type attribute will indicate either
- mixed file or mixed records as appropriate, and the binary
- formats for the non-text portions will be negotiated.
-
- Mailbagging may also require extension. In this case, the
- mode of access used by a mail donor initiating the transfer
- could be 'Append or Make', though this is not recommended.
-
- Other facilities which may be useful are: data compression,
- text formatting, record structuring, restart and resumption
- recovery facilities, account name, various passwords etc.
-
-
- 4.5 Reliability
-
- The NIFTP has several grades of recovery action, which can
- be exploited to ensure that a message will be delivered to a
- server despite the occurence of system or communication
- errors. However, the successful delivery of a message to a
- server does not guarantee it will be successfully delivered to
- the recipient. If it cannot be delivered, notification should
- be sent to the sender by the server forced to discard it,
- where this is possible. This notice will take the form of a
- message, and the sender's address will be determined from
- inspection of the appropriate fields (i.e. "Reply-to:" and
- "From:") in the message. A non-delivery notice should make
- maximum use of the NIFTP reliability procedures to ensure that
- it itself is delivered.
-
-
- 5. Mail Relays
-
- For a number of reasons it may not be possible to transfer a
- message direct between the sender and the receiver. In
- particular, they may not use the same mail transfer procedure.
-
-
-
-
- Bennett [Page 12]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- In such cases, mail must be staged through an intermediate
- mail server, which acts as a mail relay.
-
- The function of the relay is to redistribute received mail
- to the destinations or to other mail relays. I do not intend
- to specify a mail manipulation protocol here, but it is
- necessary to discuss the functions which must be provided, and
- the options which are available, in order to determine to what
- extent it is possible to allow variation and still provide an
- acceptable service. Since the actions of other mailing systems
- cannot be specified here, these functions will be discussed,
- where necessary, in relation to the NIFTP-based system
- described above.
-
- It is important to distinguish these relays from the virtual
- call gateways discussed above. Either may be used at the
- interface between two transport services, but the virtual call
- gateway gives the minimum facilities which must be provided at
- this point, and is invisible to the endpoint mail transfer.
- Mail relays must be used when different mail transfer
- protocols are used by mail donor and recipient, and will be
- visible to both the sender and recipient; in this case a
- virtual call gateway will be totally inadequate.
-
-
- 5.1 Address Processing
-
- It is not possible to prescribe an addressing format for use
- by relays, except that it be RFC733-compatible. The actions
- to be taken by the relay on processing addresses are dependent
- on local conventions and private agreements. It is expected
- that there are three major types of address processing which
- may occur:
-
- (1) The address of the next stage may be defined by a
- received <hostname> component, which is understood by
- the relay to map to the name of some other host. For
- example, the name 'Linington@Cambridge', if received
- at UCL from the US, might cause the mail to be
- transferred to Cambridge, or to some intermediate
- relay.
-
- (2) If no <hostname> is received (which can only happen
- from a non-NIFTP mailing system), the address of the
- next stage may be defined by a received <username>
- component, which is understood by the relay to map to
-
-
-
-
- Bennett [Page 13]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- the name of some other relay host, or to the
- <username> and <hostname> of the final user. For
- example, the name 'DCPU', if received at UCL from the
- US, might be understood to map to
- 'Linington@Cambridge', and be forwarded. This form is
- not encouraged as user names must then become widely
- known.
-
- (3) If the <hostname> is the relay itself, and the
- destination is not at the relay, then either case (ii)
- applies, or the username is structured in some fashion
- understood by the relay. A recommended form is
- through the use of % as a separator, which leads to a
- source-routed form, e.g:
-
- Linington%Cambridge%PSS@UCL.
-
- On reception at UCL from the US, the <hostname>
- component will be discarded, the last % converted to
- an @, and the structured name becomes:
- Linington%Cambridge@PSS. The relay then injects the
- message into the appropriate mailing system over PSS,
- subject to the constraints of that system.
-
- Any or all of these approaches may coexist. As a general
- approach, I prefer the third. All suffer from the
- disadvantages that they are not global, and that address
- transformation may be required. The user who uses relays must
- use an address format he is sure will be understood along the
- route. In practice, however, it is unlikely that more than one
- or two relays will be involved in the transfer of most
- messages.
-
- The address processing at mail relays, which may affect the
- text of the message received, must be carefully distinguished
- from the address processing which may be required at virtual
- call gateways between the donor and server, which does not.
- Two different levels of addressing are involved here - the
- former is visible only in mail, the latter only within a
- particular file transfer.
-
-
- 5.2 Return Paths
-
- The system provides no guarantee that a message can be
- replied to, although this will normally be possible. Relays
-
-
-
-
- Bennett [Page 14]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- can provide assistance in the following ways, both of which
- involve the processing of the header content of the message:
-
- (1) Each relay can insert a "Via: " field in the message.
-
- (2) Each relay can add its name to a "Reply-to: " field,
- thus building up a return source route. The name added
- must be the name known to the message system into
- which it is forwarding the mail.
-
-
- The general problem is to allow replies to be sent to
- recipients other than the sender. One possibility is to allow
- replies to be redistributed by the original sending host, if
- that host is willing to do so. Alternatively, intermediate
- relays could process the names of "To: " and "Cc: " fields in
- the message to provide a shorter path. This problem is exactly
- analogous to the "third-party addressing" problem of the UK
- Transport Service [SG3/80], and the techniques discussed in
- that document could be used here.
-
- Although this procedure requires relays to process the
- message text, programs to do such processing already exist
- which could be used for this purpose. If such processing is
- not done, it is necessary to insist that replies can only be
- sent if the recipient knows the location of the sender, which
- for full answerability amounts to a requirement for a global
- address space. This contravenes one of the stated limitations
- on the system.
-
-
- 5.3 Economy
-
- Where the mail system protocols allow, the relay should
- minimise the number of copies of a message injected into the
- system. Thus a relay may receive a single copy of a message
- destined for several different hosts, some of which may be
- only accessible through another relay. For each host which can
- be reached directly the relay will send a single copy of the
- message; for the remaining hosts, a single copy will be sent
- to the next relay which will redistribute it in turn.
-
- This minimisation may require considerable intelligence to
- do properly, and may not always be practicable. If the relay
- is receiving mail from a system which creates one copy per
- user, and injecting it into a system similar to the NIFTP-
-
-
-
-
- Bennett [Page 15]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- based system described here, there is no easy option. One
- possibility is to parse the header to identify, so far as
- possible, how many copies of the message it may expect to
- receive, detect the duplicates, and discard them. Another is
- for a relay to create a mail list and instruct a recipient to
- "Reply-to: <mail list name>@<relay>". It must then have
- criteria for deciding how long to keep such lists around. No
- doubt other equally inspiring schemes can be devised.
-
-
- 5.4 Reliability
-
- Relays should make use of the mail system to give delivery
- failure notifications, as described above. There is, however,
- no guarantee that the return path can be constructed.
-
-
- 6. The ARPA Mail Transition Plan: A Case Study
-
- In this section a proposal is made for using the NIFTP-based
- protocol to allow mail transfer between ARPANET users who have
- only NCP-based mail transfer available to them, and those who
- have only TCP-based network access.
-
-
- 6.1 Current Proposals
-
- The current proposals for ARPANET mail transition centre on
- the implementation of the MTP discussed above, and the
- definition of relay procedures between NCP-based mailing
- systems and TCP-based mailing systems [Postel80]. In general,
- these relays fit into the context discussed in the previous
- section, and most of the comments of the current proposal on
- the complexity of maintaining relays, mapping tables etc are
- fully endorsed here.
-
- Aside from the features of the MTP, there are a two specific
- points that need discussion:
-
- (1) As noted in the October 1980 Internet meeting, the
- transition plan requires that user names be unique
- throughout the ARPA Catenet (and hence a growing
- portion of the ARPANET), in order to allow ARPA mail
- from a standard ARPANET NCP-based mail server to be
- sent to a relay for forwarding to the ARPA Catenet.
- This is clearly unacceptable, and can most simply be
-
-
-
-
- Bennett [Page 16]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- avoided by allowing the relays to parse, and if
- necessary modify the header fields in the message
- text. Such solutions are preferable.
-
- (2) The solution is inextensible. The transition plans
- assumes that transfer of mail between two MTP servers
- on hosts using only NCP and TCP must be achieved
- through an MTP-based mail relay at a site with access
- to both. This is rather wasteful, since essentially
- the same protocol is involved in both cases. A similar
- relay is required if other transport services, or
- network services such as X25, require mail service.
-
-
-
- 6.2 NIFTP and the Transition Plan
-
- The major fault of the current transition arrangements
- relevant here is that a complex message relay is required even
- for hosts which both talk MTP. This is not the case for the
- NIFTP-based scheme outlined here. All that is necessary is a
- relatively simple virtual call gateway at an NCP/TCP
- transition point, along the lines discussed above. Such a
- gateway has been built and its feasability demonstrated
- [Bennett80]. Moreover, it has been demonstrated that the NIFTP
- can be readily extended to non-Catenet networks, whereas it is
- far from clear that this is true for the MTP-based scheme,
- because of its reliance on Telnet.
-
- The advantage of an explicitly network-independent approach
- is that mail transition can now be entirely divorced from
- NCP/TCP transition. The development of future mail protocols
- can carry on without requiring an immediate, new, solution for
- the Catenet. Any host with NIFTP can do direct mail transfers
- using existing formats.
-
- Of course, very few ARPANET hosts have access to NIFTP,
- although this is easy to change. However, it is not necessary
- that they should. There is indeed a staging problem to be
- solved - the staging between NIFTP-based mail and current ARPA
- mail. This must take place along the lines discussed above,
- but once solved, it is solved, in theory, not just for NCP and
- TCP but for any transport protocol.
-
-
-
-
-
-
-
- Bennett [Page 17]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- 6.3 A Proposal
-
- It is believed that an NIFTP scheme of this sort can be
- built and proliferated very quickly. The following components
- already exist:
-
- (1) NIFTP implementations written to a transport service
- interface for TOPS20 DEC20s, UNIX PDP-11s (Version 6),
- and MOS LSI-11s. These need to be upgraded to conform
- to the new specification of the protocol. The first is
- available above TCP and NCP; the second will shortly
- be accessible above TCP and X25; and the third is
- available above TCP.
-
- (2) A simple NCP/TCP virtual call gateway, for NIFTP
- support, on a TOPS20. This was built for demonstration
- purposes, and needs some modification for general use.
-
- (3) Message relays for heterogenous mail systems, in the
- form of the MMDF system developed by the University of
- Delaware [Crocker79], for UNIX. Such relays must be
- built in any case for the MTP scheme.
-
- The following components are needed:
-
- (1) Specification and agreement to the virtual call
- extensions needed for direct NCP/TCP file transfer. If
- these are done using a subset of the protocol proposed
- for implementing the UK Transport Service above TCP
- [Bennett80a] (and a similar protocol for NCP), then
- direct mail transfers from NCP sites to sites on the
- UK public network PSS could also be done.
-
- (2) Allocation of NIFTP-mail server sockets and ports.
- Again, for extension to the UK public network,
- Transport Service and/or X25 subaddresses must also be
- defined.
-
- (3) Agreement on an addressing scheme to allow transfer
- from ARPA mail to NIFTP-based sites. It is proposed
- that a structured user name of the form outlined above
- be used.
-
- (4) Implementation of an NIFTP mail channel in a form
- suitable for incorporation under MMDF by UCL.
-
-
-
-
-
- Bennett [Page 18]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- (5) At least one system in the US supporting MMDF which
- can act as a relay between ARPA mail and NIFTP mail,
- using the NIFTP channel supplied by UCL.
-
- (6) Code interfacing the transport service interface of
- the UNIX NIFTP directly to UNIX TCP (and possibly NCP)
- implementations, supplied by the US MMDF site.
-
-
- This allows us to define the minimum configuration necessary
- to provide NIFTP-based mail transfer between UCL systems and
- systems in the CONUS ARPANET using either the current ARPANET
- mail transfer protocol or the new MTP. The path would be as
- follows:
-
- (1) UCL donor passes mail to UCL UNIX NIFTP in core.
-
- (2) NIFTP initiates a connection to the remote NIFTP,
- which is which is driven as a mail channel by an MMDF
- system (e.g. SRI-UNIX or UDEL-EE). This path will be:
- through the UCL UIPP protocol to the Front End; thence
- via TCP through UCLNET, SATNET and the CONUS ARPANET,
- either directly to the remote system, or to a TCP/NCP
- virtual call gateway resident at ISIE (which in turn
- forwards the NIFTP traffic to the remote MMDF server
- through NCP).
-
- (3) The remote MMDF injects the mail into either the
- standard ARPANET mail channel or an MTP channel; at
- the remote end of which it is delivered to the user's
- mailbox.
-
-
- In addition, it would be highly desirable to construct an
- MMDF-like system which could act as a multi-channel mail relay
- on TOPS20 systems in the ARPANET. All relevant mail channels
- could be driven through it in a precisely similar manner.
- However, rather more work is required to make this service
- available.
-
- The above discussion ignores MTP-based mail altogether. This
- has been done for illustrative purposes only - I have no doubt
- that the current transition plans will be implemented, though
- possibly not quite in their current form. In practice, the two
- systems could coexist quite happily. The main impact of
- allowing the two systems to proceed in parallel would be in
-
-
-
-
- Bennett [Page 19]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- the design of mail relays. The more mail transfer systems
- exist, the more important it is that relays be designed in a
- 'mail-independent' fashion. The advantages of this have
- already been demonstrated for the UNIX MMDF. The same
- principles should be followed in the design of relays for
- other computer systems.
-
-
- 7. NIFTP-Based Mail in the UK.
-
- Within Britain, the problems of building a mail system along
- these lines are rather different, but on the whole less
- complex. The basic communications facilities are only now
- coming into widespread use, and the investment in higher level
- protocols is much lower. However, the higher level protocols
- which are coming into use are much friendlier to the system,
- for the following reasons:
-
- (1) NIFTP is already available on most widely used machine
- types in Britain. Implementing the mail transfer
- procedure is a trivial additional exercise.
-
- (2) The UK transport service proposals assume the need for
- network interconnection to provide a semantically
- equivalent service rather than a superimposed common
- protocol. Hence the need for extensibility through
- virtual call gateways is widely accepted.
-
- (3) Because there is no heavy investment in first
- generation protocols, there is no absolute requirement
- for mail relays at this stage.
-
-
- The major need is for message processing and preparation
- programs, as such programs are not widely available in the UK,
- except for UNIX systems. In particular, these should be based
- on RFC733 procedures. For many system types these may be
- available from similar systems in the US; others would have to
- be developed from scratch.
-
-
- 8. References
-
-
-
- [Bennett80] - Bennett, C. J.: The Design and Implementation of
-
-
-
-
- Bennett [Page 20]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- Transnetwork Systems. UCL TR 65. Available from
- Univeristy College London.
-
- [Bennett80a] - Bennett, C. J.: Realisation of the Yellow Book
- Above TCP. INDRA Note 965. Available from University
- College London.
-
- [Crocker77] - Crocker, D. H., Vittal, J. J., Pogran, K. T.,
- Henderson Jr, D. A.: Standard for the Format of ARPA
- Network Messages. RFC733. Available from SRI
- International, Menlo Park, California. Obsoletes earlier
- versions.
-
- [Crocker79] - Crocker, D. H., Szurkowski, E. S., Farber, D.
- J.: An Internetwork Memo Distribution Capability - MMDF.
- Proc. 6th Data Comm. Symp.
-
- [HLPG81] - HLPG/FTPIG: A Network Independent File Transfer
- Protocol. Available from DCPU, National Physical
- Laboratory, Teddington, UK. Obsoletes earlier versions.
-
- [Postel76] - Postel, J. B.: Mail Protocol. NIC 29588.
- Available from SRI International, Menlo Park, California.
-
- [Postel80] - Postel, J. B., Cerf, V. G.: Mail Transition Plan.
- RFC773. Available from SRI International, Menlo Park,
- California.
-
- [SG3/80] - PSS/SG3: A Network Independent Transport Service.
- Available from the DCPU, National Physical Laboratory,
- Teddington, UK.
-
- [Sluizer80] - Sluizer, S., Postel, J. B.: A Mail Transfer
- Protocol. RFC772. Available from SRI International, Menlo
- Park, California.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Bennett [Page 21]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- APPENDIX I
-
- RFC733 Formats
-
- Below is an example of an RFC733 message taken from the
- specification.
-
- Date: 26 August 1976 1430-EDT
- From:George Jones<Group at Host>
- Sender:Secy at SHOST
- To:Al Neuman at Mad-Host,
- Sam Irving at Other-Host
- Message-ID: <some string at SHOST>
-
- This is an example of an RFC733 message. Both
- simpler and more complex headers are possible.
-
- The entire RFC733 syntax specification is summarised in
- the following listing, extracted from the original
- specification:
- A. ALPHABETICAL LISTING OF SYNTAX RULES
-
-
- address = host-phrase / quoted-string
- / (*phrase "<" address ">" )
- / (*phrase ":" address ";" )
- / (":" ("Include" / "Postal" / atom) ":" address)
- ALPHA = <any TELNET ASCII alphabetic character>
- atom = 1*<any CHAR except specials and CTLs>
-
- CHAR = <any TELNET ASCII character>
- comment = "(" *(ctext / comment / quoted-pair) ")"
- CR = <TELNET ASCII carriage return>
- CRLF = CR LF
- ctext = <any CHAR excluding "(", ")", CR, LF and
- including linear-white-space>
- CTL = <any TELNET ASCII control character and DEL>
-
- date = 1*2DIGIT ["-"] month ["-"] (2DIGIT /4DIGIT)
- date-field = "Date" ":" date-time
- date-time = [ day-of-week "," ] date time
- day-of-week = "Monday" / "Mon" / "Tuesday" / "Tue"
- / "Wednesday" / "Wed" / "Thursday" / "Thu"
- / "Friday" / "Fri" / "Saturday" / "Sat"
- / "Sunday" / "Sun"
- delimiters = specials / comment / linear-white-space
-
-
-
-
- Bennett [Page 22]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- DIGIT = <any TELNET ASCII digit>
-
- extension-field = <Any field which is defined in a document
- published as a formal extension to this
- specification>
-
- field = field-name ":" [ field-body ] CRLF
-
- fields = date-field originator-fields *optional-field
- field-body = field-body-contents
- [CRLF LWSP-char field-body]
- field-body-contents = <the TELNET ASCII characters making up the
- field-body, as defined in the following sections,
- and consisting of combinations of atom, quoted-
- string, and specials tokens, or else consisting of
- texts>
- field-name = fnatom *(LWSP-char [fnatom])
- fnatom = 1*<any CHAR, excluding CTLs, SPACE, and ":">
-
- host-indicator = 1*( ("at" / "@") node )
- host-phrase = phrase host-indicator
- hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ]
- HTAB = <TELNET ASCII horizontal-tab>
-
- LF = <TELNET ASCII linefeed>
- linear-white-space = 1*([CRLF] LWSP-char)
- LWSP-char = SPACE / HTAB
-
- mach-id = "<" host-phrase ">"
- mailbox = host-phrase / (phrase mach-id)
- message = fields *(CRLF *text)
- month = "January" / "Jan" / "February" / "Feb"
- / "March" / "Mar" / "April" / "Apr"
- / "May" / "June" / "Jun"
- / "July" / "Jul" / "August" / "Aug"
- / "September" / "Sep" / "October" / "Oct"
- / "November" / "Nov" / "December" / "Dec"
-
- node = word / 1*DIGIT
-
- optional-field =
- "To" ":" address
- / "cc" ":" address
- / "bcc" ":" address
- / "Subject" ":" *text
- / "Comments" ":" *text
-
-
-
-
- Bennett [Page 23]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- / "Message-ID:" mach-id
- / "In-Reply-To"":" (phrase / mach-id)
- / "References:" (phrase / mach-id)
- / "Keywords" ":" phrase
- / extension-field
- / user-defined-field
- originator-fields =
- ( "From" ":" mailbox
- ["Reply-To:" address] )
- / ( "From" ":" 1 address
- "Sender" ":" mailbox
- ["Reply-To:" address] )
-
- phrase = 1*word
-
- quoted-pair = "
- quoted-string = <"> *(qtext / quoted-pair) <">
- qtext = <any CHAR except <">, CR, or LF and including
- linear-white-space>
- SPACE = <TELNET ASCII space>
- specials = "(" / ")" / "<" / ">" / "@"/ "," / ";" / ":"
- / "
-
- text = <any CHAR, including bare CR and/or bare LF, but
- NOT including CRLF>
- time = hour zone
-
- user-defined-field = <Any field which has not been defined in
- this specification or published as an extension to
- this specification; names for such fields must be
- unique and may be preempted by published
- extensions>
-
- word = atom / quoted-string
-
- zone = ( ("+" / "-") 4DIGIT )
- / ( ["-"] (1ALPHA
- / "GMT" / "NST" / "AST" / "ADT" / "EST" / "EDT"
- / "CST" / "CDT" / "MST" / "MDT" / "PST" / "PDT"
- / "YST" / "YDT" / "HST" / "HDT" / "BST" / "BDT" ))
-
- <"> = <TELNET ASCII quote mark>
-
-
-
-
-
-
-
-
- Bennett [Page 24]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- APPENDIX II
-
- UCL Mail System Plans for 1981
-
- The following is an extract from the UCL annual report
- for the Ministry of Defence, summarising our planned
- activities in 1981.
-
-
- Plans for the message systems work in 1981 have not
- been finalised, as some areas depend on decisions and
- choices which have not yet been made. However, a rough
- scheme is as follows:
-
- (1) Complete installation of MMDF in local systems
- (January). Supportive tasks will be required
- throughout the year, eg bugfixing as found,
- transferring and reconfiguring MMDF for new systems
- (eg the 11/44) as they become available.
-
- (2) Issue specification of proposed NIFTP-based mail
- channel (January)
-
- (3) Either
-
- implement NIFTP-based mail channel over TCP under
- MMDF; if possible, after upgrading UNIX NIFTP to the
- 1980 specification. Optionally (but preferably) the
- UNIX NIFTP should also use Yellow Book TCP commands.
-
- or
-
- implement or obtain MTP mail channel over TCP under
- MMDF. If one is obtained from an outside source it
- must be modified to access TCP through the UIPP, and
- very probably modified so that it can be driven as a
- channel through MMDF. (1st - 3rd quarter)
-
- (4) Depending on the choice made above, appropriate
- supportive action must be taken. (2nd to 4th quarter
- and beyond)
-
- (1) NIFTP-based channel
-
-
-
-
-
-
-
- Bennett [Page 25]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- (1) This should be released to an MMDF
- site in the US (either SRI or the
- University of Delaware) which could
- act as a relay.
-
- (2) Help and assistance as required to
- interface NIFTP directly to TCP or NCP
- in the remote system.
-
- (3) TCP/X25 virtual call gateway to allow
- access through IPSS and PSS. This
- should be in existance in any case.
-
-
- (2) MTP channel
-
- (1) TCP/X25 virtual call gateway, as
- above.
-
- (2) Possibly TCP/NCP virtual call
- gateways. This depends on the progress
- of MTP/ARPA mail relays at TCP/NCP
- boundaries as required by the ARPA
- Mail Transition Plan.
-
-
-
- (5) Replace MSG message processing system by MH, to allow
- remote access to UCL mail handling. (3rd/4th quarter
- and beyond).
-
- While the above lists the primary path to providing
- mail services, there are a number of subsidiary or
- optional pathways which will also be undertaken, if
- necessary or desirable. These include the following:
-
- (6) Continue efforts to provide ARPANET mail access
- through a terminal channel. (January/February).
-
- (7) Undertake necessary activity to incorporate
- TOPS20/TENEX systems into either the NIFTP or MTP
- based scheme above. The latter case should presumably
- involve very little UCL activity. The former case
- requires the following from us (1st to 4th quarter and
- beyond):
-
-
-
-
-
- Bennett [Page 26]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- (1) Optionally (but preferably) the upgrading of
- the TOPS20 NIFTP to the 1980 specification.
-
- (2) Optionally (but preferably) the interfacing of
- the NIFTP to a Yellow Book TCP Service.
-
- (3) The design and development of a mail relay
- system analogous to MMDF for TOPS20. Even if
- it is decided that UCL will go the NIFTP path,
- such a relay may well be developed by a US
- ARPA contractor for MTP support. In this case,
- our task is to interface the NIFTP channel on
- TOPS20 to this relay.
-
-
- (8) There may arise interest in providing mail servers
- within the UK community, eg on SRCNet or PSS. Such
- services are more likely to be NIFTP-based than MTP-
- based (though in the longer term Teletex is a more
- favoured candidate than either). In this case the
- following UCL activities would be required (2nd/3rd
- quarter to 4th quarter and beyond):
-
- (1) NIFTP-based mail channel over Yellow Book over
- X25.
-
- (2) The use of the UCL MMDF server as an actual
- mail relay, if Catenet sites are using an MTP
- channel.
-
- (3) A TCP/X25 virtual call convertor if they are
- not.
-
-
- (9) Additionally, UCL will continue to take an active
- interest in message standardisation activity, in areas
- such as Teletex, IFIP WG6.5, etc.
-
-
-
-
-
-
-
-
-
-
-
-
-
- Bennett [Page 27]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- Table of Contents
-
-
-
-
- 1. Introduction..................................................1
-
-
- 2. Requirements..................................................1
-
-
- 3. Basic Elements................................................2
-
- 3.1 Mail Format...............................................2
- 3.2 Mail Addresses............................................3
- 3.3 Mail Transfer.............................................4
-
- 4. Point to Point Mail Transfer..................................6
-
- 4.1 Mail Structure............................................6
- 4.1.1 Proposal.............................................6
- 4.1.2 Discussion...........................................7
- 4.1.2.1 Address Lists...................................7
- 4.1.2.2 Possible Extensions.............................7
- 4.1.2.3 Alternative Structures..........................8
- 4.2 Mail Server Identification................................9
- 4.2.1 Proposal.............................................9
- 4.2.2 Discussion...........................................9
- 4.3 Mail Server Communication.................................9
- 4.3.1 Proposal.............................................9
- 4.3.2 Discussion...........................................10
- 4.4 Mail Transfer.............................................11
- 4.4.1 Proposal.............................................11
- 4.4.2 Discussion...........................................11
- 4.5 Reliability...............................................12
-
- 5. Mail Relays...................................................12
-
- 5.1 Address Processing........................................13
- 5.2 Return Paths..............................................14
- 5.3 Economy...................................................15
- 5.4 Reliability...............................................16
-
- 6. The ARPA Mail Transition Plan: A Case Study...................16
-
- 6.1 Current Proposals.........................................16
-
-
-
-
- Bennett [Page 28]
-
- INDRA Note 1025 NIFTP-Based Mail
-
-
-
-
-
- 6.2 NIFTP and the Transition Plan.............................17
- 6.3 A Proposal................................................17
-
- 7. NIFTP-Based Mail in the UK....................................20
-
-
- 8. References....................................................20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Bennett [Page 29]
-